Security status and information display system

ABSTRACT

The present invention provides a system and method for reporting security information relating to a mobile device. A security component identifies security events on the mobile device that are processed on the mobile device or by a server. The security component then determines a security assessment for the mobile device based upon the detected security events. The security state assessment can be displayed in various different formats on the mobile device display or on a client computer through a user interface. The display may be persistent in the form of a desktop widget or home-screen item which enables the user or administrator to verify the functioning of security protection on the device and be alerted if the device needs attention without having to specifically seek such information.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No. 12/255,635, filed on Oct. 21, 2008, now U.S. Pat. No. 8,060,936. The present application is related to the following co-pending U.S. patent applications: U.S. application Ser. No. 12/255,632, filed Oct. 21, 2008, “SECURE MOBILE PLATFORM SYSTEM,” U.S. application Ser. No. 12/255,626, filed Oct. 21, 2008, “SYSTEM AND METHOD FOR A MOBILE CROSS-PLATFORM SOFTWARE SYSTEM,” U.S. patent application Ser. No. 12/255,621, filed Oct. 21, 2008, “SYSTEM AND METHOD FOR ATTACK AND MALWARE PREVENTION,” and U.S. patent application Ser. No. 12/255,614, filed Oct. 21, 2008, now U.S. Pat. No. 8,051,480, “SYSTEM AND METHOD FOR MONITORING AND ANALYZING MULTIPLE INTERFACES AND MULTIPLE PROTOCOLS” which are all hereby incorporated by reference.

FIELD

The present invention relates generally to methods and systems for providing security status information for display on a mobile device, or on other computers monitoring activity on the mobile device.

BACKGROUND

Mobile devices such as cell phones and personal digital assistants (PDAs) can be attacked by exploits or viruses that are specifically adapted for the mobile environment. Exploits can take advantage of security vulnerabilities associated with a mobile device in order to execute malicious code or perform undesired actions on the device. Potentially, exploits can bypass permissions or policies set by the user, manufacturer, operating system, or mobile operator and give the attacker complete control of the device. Mobile viruses are typically spread by downloading infected programs or files. Some viruses only become active if the recipient chooses to accept the virus file and run it on the mobile device. Other viruses, when combined with exploits, are self-propagating worms that may not need user intervention in order to spread, potentially creating a very severe and widespread security problem.

Devices may be compromised by viruses and exploits over wide area networks, such as the Internet or a cellular network, and local wireless networks, such as Wi-Fi or Bluetooth. For example, some devices which are equipped with Bluetooth allow other nearby Bluetooth-enabled devices to transfer files or other data such as contact information. Bluetooth-enabled devices that are infected with viruses often search for nearby devices that are in “discoverable” mode. When an infected device discovers a target, it may send a virus disguised as a security update or another item designed to fool the target device's user into accepting the transfer and executing the virus. If a virus were to utilize an exploit instead of disguising itself in order to get a target user to accept the file transfer, a device which is in “discoverable” mode could become infected without the user being able to intervene.

In addition to being able to propagate viruses, exploits may be able to directly perform malicious actions on vulnerable devices. Such exploits may be used by attackers to steal information, charge money to the target device's phone bill, or prevent a device from functioning properly. Although vulnerabilities which take advantage of exploits may be fixed if the software vendor responsible for the vulnerability provides a patch or firmware upgrade, such fixes are often costly and time consuming to release and difficult for users or IT organizations to apply.

It is important that both individual users and IT organization be able to verify that their security protection is functioning properly and be aware of the security state of their devices so as to be able to remediate or investigate issues as early as possible. If a device or group of devices has a security problem or has recently been attacked, the user or administrator responsible may not immediately know because mobile devices and existing solutions may not continuously present security status information and attempt to push important events to users and administrators.

What is needed is a system and method for identifying, reporting, and preventing mobile security problems and for providing security information concerning the state of a mobile device or group of mobile devices to a user or administrator. The system and method should keep users or administrators continuously aware of security status, recent security-related events, and potential security threats without requiring them to repeatedly seek out security-related information.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which:

FIG. 1 is an exemplary block diagram depicting an embodiment of a mobile device which detects and processes security events;

FIG. 2 is an exemplary flow chart illustrating the processing of security events on a mobile device;

FIG. 3 is an exemplary block diagram depicting an embodiment of the present invention in which security events detected by a mobile device are processed on a remote server;

FIG. 4 is an exemplary flow diagram illustrating the processing of security events on a server;

FIG. 5 is an exemplary home screen graphical user interface for the mobile device;

FIG. 6 is an exemplary security screen graphical user interface for the mobile device;

FIG. 7 is an exemplary web based mobile device security status display; and

FIG. 8 is an exemplary e-mail summary of the mobile device security status.

FIG. 9 is an exemplary messaging diagram illustrating the flow of communications according to an embodiment of the present invention.

DETAILED DESCRIPTION

It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium such as a computer readable storage medium comprising computer program instructions or a computer network wherein computer program instructions are sent over optical or electronic communication links. Applications, software programs or computer readable instructions may be referred to as components or modules. Applications may take the form of software executing on a general purpose computer or be hardwired or hard coded in hardware. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

The present invention is directed towards a system that displays the security status and security event information for a mobile device running security software. In an embodiment, the mobile device has a security system that runs on the mobile device which analyzes network data and files for security threats and determines the security state of the mobile device. The security system produces graphical displays indicating the security state of the mobile device and detailing the security events that have been detected and processed. In this embodiment, the mobile device may obtain periodic updates of mobile virus information from a server. The mobile device may also send the security information to a server for display on a computer to permit monitoring of security information relating to the mobile device.

With reference to FIG. 1, a block diagram of an embodiment of the mobile device 101 is illustrated. The mobile device 101 can include: an operating system 113, an input device 115, a radio frequency transceiver(s) 117, a visual display 121, database of security event information 123, and a battery or power supply 119. Each of these components can be coupled to a central processing unit (CPU) 103. The operating system 113 runs on the CPU 103 and provides an interface between security system application programs and the mobile device hardware.

The inventive system can receive data through an RF transceiver(s) 115 which may be able to communicate with various other electronic devices. The RF transceiver(s) 115 can transmit and receive data over various networks, for example: Bluetooth, local area networks such as Wi-Fi, and cellular networks such as GSM or CDMA. The RF transceiver(s) 115 can transmit and receive various types of data including voice, text, photos, video, SMS messages, applications, etc. All forms of data packets can be analyzed and processed by the inventive system. Additional details about the analysis and processing of data is described in U.S. application Ser. No. 12/255,614, filed Oct. 21, 2008, now U.S. Pat. No. 8,051,480, “System and Method for Monitoring and Analyzing Multiple Interfaces And Multiple Protocols.”

In an embodiment, a local security component 105, an information gathering component 107 and a transport component 109, can be application programs that are downloaded and integrated with the mobile device operating system 113. Much of the source code for these security components can be re-used between various mobile device platforms by using a cross-platform software architecture. The local security component 105, an information gathering component 107 and a transport component 109 provide specific security status information which can include an overall security state and security event information. Additional details of the mobile platform system and the processing performed by the security components are disclosed in U.S. patent application Ser. No. 12/255,632, filed Oct. 21, 2008, “Secure Mobile Platform System” and U.S. patent application Ser. No. 12/255,621, filed Oct. 21, 2008, “System and Method For Attack And Malware Prevention.”

In an embodiment, a device's state may be sent to server 629 so that it has the most updated security information about the device. This security state information may also include the device's identifier, configuration, settings, information on recent security events, as well as the device's state. As shown in FIG. 9, mobile communications device 627 may send this security data to server 629 over the network (step 631). In step 633, server 629 may acknowledge receipt of the security data from device 627.

In an embodiment, the local security component on the mobile device can identify security events by analyzing files or data stored on the device, messages such as function or system calls between components on the device, or network data flowing into or out of the device for security events. The security events can include finding possible threats such as exploits, suspicious network traffic, viruses, malware, SMS message or phone call spam, suspicious system or function calls, authentication failures, etc. For example, virus detection can be performed using a list of virus signatures. The local security component 105 can examine the contents of the mobile device memory and compare those files against a database of known virus “signatures.” In other embodiments, the local security component 105 may also utilize an algorithm that performs virus detection based on common virus behaviors or common virus characteristics. This alternative virus detection has the ability to detect viruses that do not have known virus signatures. Additional details regarding alternative attack and malware prevent systems are disclosed in U.S. patent application Ser. No. 12/255,621, filed Oct. 21, 2008, “System And Method For Attack And Malware Prevention.”

In addition to the detection of viruses, the local security component 105 can also detect security threats facing the device over various network interfaces. In an embodiment, the local security component can analyze network data using any combination of a “known bad” network data detection component, a “known good” protocol content and statefulness analysis component, and a decision component. Upon examining the network data, the local security component 105 may identify security events including: a protocol length mismatch, a protocol value violation, a value violation for a protocol in a given state, a protocol state transition violation, a firewall rule violation, a known bad piece of network data, or a piece of network data decided to be bad. Once a security event has been identified and associated with incoming or outgoing data, the local security component 105 can determine how to protect the mobile device.

Table 1 below is a listing of some possible events that can be detected by analyzing the files or data stored on the device, function or system calls, or network data and example associated severity levels. The severity level can vary depending both on the event type and the parameters associated with an event. For example, regarding an event corresponding to a virus scan, if no viruses are found, the event would have a low severity. If a virus was found, but it was quarantined, the severity would be slightly higher. If a virus was found, but it could not be quarantined, the severity level would be high.

TABLE 1 DETECTED EVENT SEVERITY (MAX. 5) Virus scan (1 virus found, 0 viruses quarantined) 5 Known bad data 4 Virus scan (1 virus found, 1 virus quarantined) 3 Decidedly bad data 3 Virus found and quarantined 3 Protocol length mismatch 3 Protocol value violation while in specific state 3 Protocol value violation 3 Protocol state violation 2 Local authentication failure 2 Spam blocked 1 Firewall rule violation 1 Virus scan (No viruses found) 0

The local security component 105 sends the security event information to the information gathering component 107 that quantifies the security events and the severity of the security events. For example, the information gathering component 107 processes the detected security events and produces security state assessment results for the mobile device 101. In an embodiment, the security state assessment includes an overall security condition of the mobile device. The security state assessment is also displayed as a graphical representation of the number of security events detected, a chart illustrating the rate of security events detected by the local security component 105 and other visual representations of security related status information. In an embodiment, the overall security assessment condition of the mobile device can range from “Everything is OK” when no severe security events are detected to “Infected”, when a virus is detected on the mobile device. Other overall security assessment conditions include “Compromised”, when the local security component detects that an exploit or other attack has been successful on the device or the trust model has been otherwise compromised, “Warning”, where the local security component 105 is not configured for optimal security or other user action is desired, and “Error”, where there are problems with the security of the mobile device that need to be fixed.

The security status information includes an overall mobile device security state as well as additional information about specific detected security events. The security event information is presented in various forms including: charts, graphs, graphical displays and text. The security event information presentation may vary depending upon the display on the mobile device on the client computer. The security status data displayed on the mobile device itself can be in a substantially different format than similar information about the mobile device displayed on the client computer, website or e-mail.

In an embodiment, when data is sent or received by the RF transceiver 115, aspects of the data are analyzed by the local security component 105 to determine if the data should be identified as a security event and if actions should be taken. As noted above, the assessment may involve one or more possible security analysis components, including a known bad analysis component, a known good analysis component, and a decision component. The local security component 105 stores and processes the data concerning security events and determines an overall device-wide security state assessment. The security component 105 also forwards the individual and cumulative security event information to the information gathering component 107 for further processing and producing graphical representations of the device-wide security state. The security state of the mobile device is displayed in the form of a graphical security status icon, security event charts and various other outputs that communicate security information about the mobile device 101. The graphical data is then sent to the transport component 109 which forwards the security state assessment data to a visual display on the mobile device. In another embodiment, the mobile device security information is transmitted to a server(s) and a client computer(s) for display on a device remote from the mobile device.

The processing of data such as files or data stored on the device, function or system calls, or network data, by the mobile device 101 is illustrated in more detail with reference to FIG. 2. The data is received by the local security component 211. The local security component analyzes aspects of the data to determine if a security event is detected 213. If no security events are detected, the data is determined to be safe and is processed normally by the mobile device 215. In the preferred embodiment, the screened safe data will pass through the local security component in a transparent manner.

If the local security component onboard the mobile device detects a security problem with the data, one or more security events may be triggered. The local security component automatically performs defensive actions to protect the mobile device 101 from the immediate threat. The event or events generated will be processed 217 in order to determine if further actions need to be taken. The type of defensive processing performed by the local security component depends upon the context and type of data being analyzed. For example, the system can drop network data considered to be harmful or may disconnect one or more protocol connections associated with the data. The security component produces an event log that is stored and updated as new events are detected. Although monitoring of the security events is primarily directed towards data, hardware defects may also create security events. For example, physical damage, dead batteries or other defective hardware in the mobile device can cause the security component to detect a security event.

In an embodiment, the local security component analyzes the cumulative security events and the non-security event data to determine an overall security status for the mobile device 219. This security assessment is based upon the type, severity and quantity of the security events, their associated data, and the non-security events and data that are received and processed by the mobile device 101. The information gathering component further processes the security and non-security event data by creating various graphical and text based outputs for the security related information. The data processed by the information gathering component is sent to the transport component which controls how and where the security status will be displayed. The transport component displays the determined security status on the mobile device 221.

In addition to displaying the security status on the mobile device, the security status as well as events and event data can be forwarded to a server 111. The server may further process the events, event data, and security status information and/or output the status information to other electronic devices. A security status signal can be transmitted to a client computer 233 associated with the mobile device 101 through a security widget. In an embodiment, the widget may provide a perpetual display such as text or an icon that provides a graphical indication of the security status of the mobile device on the desktop or an operating system tool bar of the client computer. The security status information can also be output to a web site or database configured to provide content for a web site 235 for access through a web browser. The server 111 also sends e-mails 237 to an electronic address with security status updates and/or event summaries for the mobile device(s) being monitored. The system may require user authentication procedures before allowing remote access to the mobile device security information.

In an embodiment, the mobile device 101 also downloads updated security event information as well as other software and database updates from the server 121. If the mobile device and the client computer are coupled to the same network, it may be possible for the mobile device to transmit the security state information directly to the client computer, allowing the security assessment information to be displayed on the client computer.

With reference to FIG. 3, an alternative configuration of the mobile device security system is illustrated. The mobile device 101 is coupled to a server 111 and the server 111 is coupled to a client computer 233 by the network 121. In this embodiment, the server 111 can include a remote security component 125, a remote information gathering component 127 and a remote transport component 129. The server can also contain a database 131 of security event information including: virus, malware, and network-based attack, and other security threat identification information. The mobile device 101 analyzes files or data stored locally, function or system calls, and/or network data; identifies security events; and forwards data concerning the events to the server 111 for processing. Like the local security component described above, the remote security component 125 processes the data concerning the security events to assess a security state of the mobile device. In this embodiment, the server 111 can receive raw data or data that has been partially or fully processed by the mobile device 101.

The remote security component 125 might also receive data concerning non-security events to determine an overall security status for the mobile device. In an embodiment, the server 111 can transmit the security status and the security event data back to the mobile device 101 for display. The server 111 can also transmit the security data to a remote client computer 233 through a client computer widget, a web site 235 or via e-mail 237. The security event information can include the overall security assessment and specific security events detected which are displayed on graphical user interfaces.

With reference to FIG. 4, a flow chart of the mobile device with server embodiment of the present invention is illustrated. The mobile device 101 receives data 311 such as files or data stored locally, function or system calls, and/or network data from an internal or external source. The data is then analyzed by the security component for security events 313. If a security event is not detected by the local security component, the mobile device 101 processes the data normally 315. If a security event is detected, the event and its associated data is forwarded to the server 111 for processing 325 by the remote security component which performs many of the same function as the local security component in the mobile device 101 described above.

The remote security component will process the security event data in a manner corresponding to the type of security event detected in order to extract more information from the events and determine an accurate assessment of the security state of the device. For example, the security component on the mobile device 101 may have identified incoming network data as having a length mismatch. The security event is sent to the server 111 which may have information that identifies this specific length mismatch as a very dangerous attack attempting to exploit a recently discovered vulnerability in the mobile device's software. Such an event may be given very high severity to alert the user or administrator responsible for the device 101 about the attack. In another example, a mobile device 101 may run an executable file that is not considered to be a virus by the local security component. The device 101 sends an event corresponding to the execution of the file to the server 111 and the server 111 having more comprehensive virus signature information, may identify the file as a virus and determine the event to be severe. Automatic or manual defensive intervention can be performed to remove the infection. Various other processing can be performed for malware and other types of security events.

The remote security component may receive information about both security event and non-security-event data received by the mobile device. Based upon this cumulative data, the remote security component can determine an overall security status or assessment for the mobile device 327. If it the server 111 were to determine that the security component on the mobile device 101 was unable to stop any sort of security attack or virus/malware infection, the server 111 would update the device's security status accordingly. If needed, the server 111 may transmit commands to the device to remediate one or more security problems associated with events 317. These commands may be specialized for the particular virus or other security threat identified by the processing of one or more security events. The information gathering component can process the event information to produce charts, graphs, text outputs and graphical representations for the security state for the mobile device 101. The information gathering component at the server may also produce a log of security events for the mobile device. A transport component can then output the security event information to the mobile device 101 for persistently displaying the overall security status 321. The security event information can also be output by the server 111 to client computers 233 through a direct communication with a widget installed on the client computer 233. The widget will display the security status of the mobile device 101 on the client computer 233. Alternatively, the server 111 can post the status information for the mobile device 101 to a web site 235, which is accessible to client computers 235. The server 111 can also transmit the status information by e-mail to an address 237 associated with the mobile device.

As discussed, the processing of the security events can be performed by the local security component or a remote security component on a server. Because both modes of operation are automated, the functionality of both modes can appear identical to the user of the mobile device. A functional difference between the two modes of operation can be the updating of virus or other attack signatures. In order for the local security component to specifically identify current viruses and attacks, the signatures must be updated regularly. The mobile device can be configured to obtain updates automatically or manually. In contrast, the security event database on the remote server is maintained by the service provider and will always have the most current updates. Another difference is that the communications between the server and mobile device may not be persistent. While the server will normally be able to transmit and receive information persistently, the mobile device can be out of service periodically. The mobile device may not be in a good service area, the battery may be dead or the mobile device is turned off. There are various other reasons that the mobile device temporarily may not be able to transmit and receive data. Since communications may not be persistent, the security status information may need to be transmitted from the server to the mobile device in a store and forward manner. More specifically, the server may determine the mobile device security state and this information may need to be stored on the server until the mobile device is ready to receive data again.

With reference to FIG. 5, mobile devices often have a home screen 401 that displays important information the user may want to see at-a-glance and is typically the default screen that a user can easily navigate to. Common information on such a screen includes the number of unread emails 411, the number of unread SMS messages 413, the number of missed calls 415, a calendar 417 with upcoming appointments, contacts 423, the current date 421 and time 419, and other frequently needed information. A home screen 401 may also be called a “today screen,” a “desktop,” or other term. In an embodiment, a portion of the home screen displays security-related information. The security-related information contains an icon 405 which graphically represents the current security status of the device and text which may contain the security state of the device or other information such as settings that need attention, the number of recent events 425, a description of a recent severe event, or actions that the user needs to perform in order to keep the device secure.

The icon 405 can be displayed in a dynamic manner that includes in the image an indication of the overall security status of the mobile device. For example, the color of the icon 405 can be a visual representation of the current security status. In an embodiment, a green icon may indicate that “everything is OK”, a yellow icon may indicate a potential problem and a red icon may indicate that the device's security needs immediate attention. By activating the portion of the home screen displaying security information 405, 425, the user may be taken to an interface where they can perform needed actions or where they can view additional security-related information. This security screen allows the user to verify that their protection is working and immediately be notice if there are any security issues that may need attention. Because the home screen 401 is very often displayed, security information is pushed to the user in a perpetual display without the user having to request it. Such an embodiment may increase the user's attention to security and ability to react to security issues quickly.

With reference to FIG. 6, an exemplary security screen 301 for a mobile device is illustrated. As discussed above, the security event information is communicated from the local or remote security component to the mobile device display. The status of the mobile device can represent an assessment of the overall security condition of the device. In this example, the status of the mobile device indicates that “Everything is OK” 351. This status can also be indicated by a status icon 357 which can be color coded as described above. If the device is in a non-secure state, the status would indicate that the device is “Infected with a virus” if there had been an un-remediated virus event or “Compromised” if there had been a successful exploitation. If the user had, for example, turned anti-virus protection off, the status would indicate a warning that the user needs to “Check settings”. If there had been an internal error, the status would indicate “Error”.

In an embodiment, the GUI includes an icon 353 located next to the text which also represents the overall status of the mobile device. The overall security status of the mobile device can be indicated by a color or type of icon 353 displayed. As discussed above, a green icon may indicate that everything is OK, a yellow icon may indicate a potential problem and a red icon may indicate a high severity security event. Similarly, the type of icon can indicate the status, such as a check mark indicating that everything is OK, a question mark may indicate a potential problem or an exclamation point indicating a known security problem. By activating the portion of the display surrounding the icon 353, a corresponding action screen can be displayed. For example, activating the portion of the display surrounding the icon 353 can cause the system to display details about the security settings of the mobile device.

In addition to the display of an overall security status for the mobile device, various other mobile device security data can be displayed on the GUI of the mobile device. In an embodiment, the information gathering component can also produce a security event chart 355 that is a graphical representation of the data being analyzed by the mobile device. The color of the graph may indicate the current security state of the device. For example, if the device is in a secure state, the graph would be green. If the device is in a warning state, the graph would be yellow. If the device is in an insecure state, the graph would be red. In an embodiment, the vertical axis of the chart 355 may represent the number of analysis actions performed by the mobile device and the horizontal axis may represent time. In this example, the graph scrolls left with the most recent data plotted on the right side and the older data on the left side. After a period of time has elapsed, the data is removed from the screen. The graph can be updated at regular time intervals such as every second. The vertical scale can be scaled for the largest number of detected events per time period. In an alternative embodiment, the chart 355 can represent the number of security events that have been detected over a given period of time.

Additional security information that can be displayed on the mobile device display includes: the total number of security events detected in a time period, the last time the mobile device has connected to or synchronized with a server, and the last time the mobile device was scanned for viruses, malware, and other security threats. In this example, 31 security events have been processed by the security system 361, the mobile device data was synchronized 20 minutes ago 363, and the mobile device was scanned 20 minutes ago 365. In an embodiment, clicking on any of these text displays will cause a corresponding action screen to be displayed.

The mobile device GUI can also include user controls that provide additional information to the users. By clicking on the “view” 371 control, the screen will display more information about the detected security events. Clicking the “sync now” 373 control causes the mobile device to synchronize the mobile device data stored locally with a remote back up copy of the data stored on the server. The “scan now” 375 control will allow the user to initiate a security scan of the mobile device. The system may also have controls that enable the user to set a desired format and layout for the security information output on the visual display 115.

While many of the controls are directly accessible from the main screen, the user may be able to access additional security controls by selecting the “menu” button 331. This can cause a pull down window of additional controls to be displayed. The pull down displays can include controls and information such as: view events, synchronize now, scan now, settings, about and exit. By clicking on the setting button, another pull down menu that lists system controls settings can be displayed. The user can then select the system controls and make any desired adjustments.

Many of the controls, such as scan and synchronize, can be performed automatically at time intervals set by the user, or at default time intervals. In an embodiment, the user can select the time interval and the time of day for performing these tasks. If a longer time period for software updates is selected such as once a week, the user can select the day of the week to perform this system maintenance. In an embodiment, the system also allows the user to select the communications mode preferences for the system maintenance such as only using a local area network or only using cellular networks while not roaming. Similar preference controls may be available for the other system controls. For example, the synchronization settings may allow the user to select the type of data to synchronize including: contacts, pictures, documents, call history, SMS messages, audio files and video files. The attack protection settings can allow the user to select the data paths that are protected including: cellular networks, Wi-Fi or other networks, Bluetooth, and short message service (SMS). The anti-spam settings can include blocking SMS and call spam based on pre-set or configurable criteria.

As described above, the mobile device and remote server can also be in direct or indirect communication with a remote client computer. In an embodiment, a widget can be installed on the client computer that allows the mobile device security status to be automatically transmitted from the server to the client computer and displayed in a persistent manner. The user or administrator responsible for a device or group of devices needs to enter authentication information to allow the widget to connect to the server and retrieve information. In this embodiment, the widget can persistently display status and security information corresponding to a device or group of devices in a manner similar to the persistent indicator displayed on the mobile device. For example, if an administrator's widget is configured to represent a group of devices, when all of the devices are in good security states, the widget will display that all of the devices are secure. In the secure state, the widget may display informational statistics such as the number of items backed up or the number of security events processed for the group. If the one or more devices are in a compromised or other insecure state, the widget will prominently display the devices that need attention to the administrator. If the widget indicates that one or more devices need attention, the administrator may click on portions of the widget to access additional security information pertaining to any of the devices that need attention.

In an embodiment, the security status widget corresponding to a single device or group of devices displays device information such as battery level, number of security events, recent data backed up, or other relevant data. The persistent indicator may also be embodied on an operating system tool bar as an icon representing the security state of a device or group of devices. As discussed above with reference to the security status icon in FIG. 5, the icon can have a dynamic aspect in that the color or display of the icon can be an indication of the overall security state of the mobile device. A green icon may indicate that everything is OK, a yellow icon may indicate a potential problem and a red icon may indicate a high severity security event. In an embodiment the type of icon can also indicate the status. For example, a check mark indicating that everything is OK or an exclamation point indicating a problem. The user can click on the icon to access additional security information for the mobile device. For example, the system can also provide a screen that displays other security event information for the mobile device in a graphical or text formats.

Additional security information can also be accessible through a web interface that can provide security information for a mobile device or group of mobile devices. In this embodiment, an administrator responsible for a device or group of devices can access the security status for one or more mobile devices on a single web interface. For example, an organization or family may have members who each have one or more mobile devices. In order to monitor the security status of all devices, the transport components on each of the mobile devices can be configured to transmit status and security information to a server. The server then processes the security information and displays the security status for each of the mobile devices on an administrator's computer that is in communication with the server. By displaying the security status of all mobile devices in the group, the administrator can quickly identify a device or devices that need attention.

In an embodiment, the administrator's computer is configured to remotely control each of the mobile devices. If a mobile device is deemed to be in a compromised, infected, or other bad security state, the administrator or user responsible will be informed and can take defensive actions to fix or investigate the device in order to protect other mobile devices, protect the data stored on the mobile device, and investigate the source of any attacks. For example, if a destructive virus is detected on a mobile device, the administrator can transmit a command to lockdown or reset the infected mobile device to prevent the virus from spreading. In an embodiment, the server may be configured to automatically take certain actions upon certain security information being received from the device. Additional details of the remote control of the mobile devices are disclosed in U.S. patent application Ser. No. 12/372,719, filed Feb. 17, 2009, “System And Method For Remotely Securing Or Recovering A Mobile Device.”

In other embodiments, a user can check the security status of one or more mobile devices through a security status web site. In order to access the web based status information for the mobile device, the user will log onto a web site by providing security information to verify access authorization. Security information can include identification and password protection or various other security screening methods. With reference to FIG. 7, an exemplary web based mobile device information page displayed on a client computer display is illustrated. Since there is typically more room on the client computer display than the mobile device display, the system can display additional information. In this example, the identification 503 and status text 505 and status icon 509 for the mobile device are provided on an upper center portion of the display and a listing of system controls 507 are placed in another area. Many of these controls are the same as the controls on the mobile device described, however these controls allow the client computer to remotely control the operation of the mobile device.

The web based display can also include additional security information about the mobile device such as backed-up data, software updates, and security events processed during the past few days 511. If any events merit user attention, those events may be specifically identified on the news feed 511. For example, if a device detected a virus or was found to be compromised by an attack, those events would be identified on the home screen. The display may identify the security status of each area of the security system including Anti-Virus, Data Protection, Attack Protection and Anti-Spam 513. The display may also include a graphical representation of the security events over the last day, week and month 515. In this example, the described display information is available on the “Home” tab 519. Various other control tabs can be available such as account 521 and administrative 523 pages which include associated controls and information. The illustrated display represents an example of a mobile device security status display. In an embodiment, the user can control the appearance of the web page through preference settings.

In another embodiment, the status of the mobile device can be transmitted to a client (other than the mobile device itself) through e-mail. An exemplary mobile device security status e-mail letter is illustrated in FIG. 8. The e-mail indicates that attack protection is disabled for the device 611, 14 security events have been handled by the system 615, a virus scan has been completed with no viruses found 617, and 1 SMS message has been received by the device 619. The e-mail also provides an identification of the mobile device. In this example, the phone number 621 identifies the mobile device. The quantity of data being protected 623 is also specified. The e-mail may include a link to the mobile device security status home page 625 which is illustrated in FIG. 6. In this embodiment, a current security status e-mail can be automatically sent based upon the user's preferences, such as daily and/or when a high severity security event is detected. The recipient or mobile device user may also be able to configure the information provided in the e-mail according to his or her personal preferences.

As critical infrastructure, mobile devices have a central role in the functioning of government, business, emergency response, and many other necessary functions of a country. Cyber-terrorism attacks on mobile devices or mobile infrastructures can result in disastrous service outages and the compromise of sensitive data. This system and method materially help defend mobile devices from cyber-terror attacks both by directly preventing attacks on devices and by allowing administrators responsible for mobile device deployments to recognize attacks as early as possible in order to put appropriate protective measures in place. Furthermore, this system and method enables administrators to quickly investigate the source and damage caused by cyber-terror attacks.

One will appreciate that in the description above and throughout, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one of ordinary skill in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate explanation. The description of the preferred embodiments is not intended to limit the scope of the claims appended hereto. 

What is claimed is:
 1. A method comprising the steps of: providing a local security component on a mobile device; acquiring by the local security component data concerning a current configuration of the mobile device; receiving at the local security component from one or more other applications running on the mobile device raw or partially processed data about events on the mobile device; processing the received data by the local security component against a database containing identification data for security threats and against the current mobile device configuration data to assess a security state of the mobile device, the processing including assigning by the local security component a severity level for each event; outputting by the local security component to the mobile device the security state assessment results, including a first assessed security state of the mobile device by the local security component for persistent display of the current security state assessment on a mobile device display home screen; transmitting the raw or partially processed data about events on the mobile device to a server for processing at the server; receiving, at the mobile device, a second assessed security state of the mobile device from the server; and displaying the second assessed security state on the mobile device display, wherein the second assessed security state by the server is different from the first assessed security state by the local security component.
 2. The method of claim 1, wherein the outputting step further includes outputting the security state assessment results from the mobile device to a server.
 3. The method of claim 1, wherein the outputting step further includes outputting the security state assessment results from the mobile device to a client computer for display on the client computer.
 4. The method of claim 1, wherein the processing step further includes a severity assessment of security events on the mobile device to determine severity levels for the security events, and wherein the outputting step includes outputting the security severity level determination for display on the mobile device display home screen.
 5. The method of claim 1, wherein the outputting step further includes outputting a list of security events for display on the mobile device display home screen.
 6. The method of claim 1, wherein the outputting step further includes outputting a list of security events from the mobile device to a client computer for the display of the list of security events on the client computer.
 7. The method of claim 1, wherein the outputting step further includes outputting a chart indicating security events on the mobile device for display of the security event chart on the mobile device display.
 8. The method of claim 1, wherein the outputting step further includes outputting from the mobile device to a client computer a chart indicating security events on the mobile device for display of the security event chart on the client computer.
 9. The method of claim 1, wherein the outputting step further includes outputting a status indicator signal representing a current security state assessment for the mobile device for persistent display of the status indicator signal on the mobile device display home screen.
 10. The method of claim 1, wherein the outputting step further includes outputting from the mobile device to a client computer a status indicator signal representing a current security state for the mobile device for display of the status indicator signal on the client computer.
 11. The method of claim 1, wherein the outputting step further includes sending an e-mail to a client computer that includes a current security state assessment for the mobile device.
 12. The method of claim 1, wherein the outputting step further includes generating a webpage that includes an indication of the current security state assessment for the mobile device.
 13. The method of claim 1 wherein the assigning further comprises: if a first event indicates malware was found and quarantined on the mobile device, assigning by the local security component a first severity level to the first event; if the first event indicates malware was found and not quarantined on the mobile device, assigning by the local security component a second severity level to the first event; and if the first event indicates no malware was found, assigning by the local security component a third severity level to the first event, wherein the third severity level is different from the first and second severity levels, and the first severity level is different from the second severity level.
 14. The method of claim 1 wherein the assigning further comprises: if a first event indicates blocking of spam, assigning by the local security component a first severity level to the first event.
 15. The method of claim 1 wherein the assigning further comprises: if a first event indicates a firewall rule violation, assigning by the local security component a first severity level to the first event.
 16. A method comprising the steps of: at a server security component running on a server, receiving from a client security component running on a mobile device raw or at least partially processed data about a security event identified by the client security component; at the server security component, receiving data concerning a current configuration of the mobile device; at the server security component, processing the received security event data and the received current mobile device configuration data against a database of security events including at least three of the security events in the group of security events consisting of exploits, suspicious network traffic, viruses, malware, SMS message spam, phone call spam, suspicious system calls, suspicious function calls and authentication failures, to assess whether the security event represents a present threat to the mobile device on which the event occurred; and at the server security component, outputting a mobile-device-specific security state assessment for display.
 17. A method comprising the steps of: at a server security component running on a server, receiving from a client security component running on a mobile device raw or at least partially processed data about a network interface event identified by the client security component; at the server security component, receiving data concerning a current configuration of the mobile device; at the server security component, processing the received network interface event data and the received current mobile device configuration data against a database of network interface events to assess whether the network interface event represents a present threat to the mobile device on which the event occurred; and at the server security component, outputting a mobile-device-specific security state assessment for display based upon the server processing. 